A digital data processing system has three basic components, a processor, a memory, and a set of input-output devices. The processor manipulates data based on a set of programmed instructions. The memory functions as a storage area for both the data and the processor instructions. The input-output devices serve as ports through which data is introduced into the system and through which the results of the data processing are presented. Digital data processing systems comprising general purpose computers are designed to manipulate and process different types of data based on the instructions with which they are supplied. Other digital data processing systems are custom built to process specific data in order to determine specific results. One such customized system is the data processing that is built into a cardiac monitor. This system monitors certain physiological parameters, such as the blood pressure and blood temperature of a patient and, based on these parameters, determines how well the patient's heart is functioning.
The instructions and data for many digital data processing systems are contained in software blocks called modules. Typically, a module is designed so that, when it is run on a digital data processing system, it will perform one or more of the intermediate tasks the system needs to perform to determine the desired result. An advantage of designing software in module form is that the individual modules can be developed and modified independently. This makes it easier to optimize each module as well as making it easier to maintain the software. Moreover, a software module developed to accomplish a given set of tasks becomes a building block for use in any digital data processing systems that need to perform those tasks as part of their overall operation. Access to a library of modules reduces the costs associated with having to write new software each time it is necessary to instruct digital data processing systems to perform the tasks for which modules have already been developed. For example, a software module designed to read a blood pressure gauge can be incorporated in different data processing systems that read such a gauge in order to accomplish the task for which they are designed.
The development of modularized software is often limited by the need to provide a data link between the individual modules. A software module, for example, that calculates heart rate needs to receive an indication of the patient's fluctuations in blood pressure. These data are produced by the software module that monitors the pressure of the blood pressure gauge. To date, a number of mechanisms have been developed to facilitate the transmission of data from software modules that generate data, called data producers, to software modules that need the data to function, called data consumers. Each of these mechanisms has design requirements that can limit its utility. One such mechanism is implemented as a direct dispatch process. In this process, a data producer sends messages containing the data to each data consumer module that requires the data. Whenever multiple data consumers require the same data, the data producer must create and transmit identical messages containing the data to the individual consumers. Each time a data-producing module is installed in a new software package, it must be provided with a set of instructions that contain the directions that indicate to which data-consuming modules it should send the data. The requirement of having to add a new set of instructions to each data-producing module each time there is need to supply the data it produces to a new data-consuming module detracts from the universality of the module. Furthermore, as the number of modules in a software package increases, the task of keeping track of which modules supply what data to other modules, in order to efficiently design the instructions integral with each module, becomes increasing difficult.
Still another data transfer process currently in use requires the data-consuming modules to retrieve the data from the data-producing modules. Each data-consuming module must be provided with instructions that direct it to query each data-producing module from which it receives data in order to obtain the desired data. Moreover, each data-producing module must be provided with an appropriate set of instructions that set a flag to indicate that it has a specific type of data available for a complementary data-consuming module. Since each data-producing module must typically set a separate data-available flag for each data-consuming module for which it has data, as the number of modules that require data rises, the complexity and length of the necessary flag-setting instructions similarly increase.
Sometimes data processing systems are provided with shared memories. In such a system, the data producer writes the data into a selected memory location. The data consumers that require that data are provided with instructions directing them to retrieve the data from that memory location. While this mechanism has some advantages, it is not without limitations. The data-consuming modules typically need to be informed that new data are available so that they execute the process steps necessary to retrieve the data. If there are numerous data-consuming modules for the same data, the resultant system can then have the same complexity as those found in direct dispatch systems. Also, in many data processing systems, only one data-consuming module can read the data in shared memory locations at any given instant. Sometimes a data-producing module will overwrite new data into the memory between the times when the memory is accessed by different consumers. The various data consumers will then perform their processing on different data, which can lead to obviously undesirable results. Attempts have been made to solve this problem by providing the shared memories with first-in/first-out buffers that store different versions of the data, or with multiple memory slots in which multiple copies of the same data are stored. A disadvantage of these mechanisms is that they can be as cumbersome to control as regular point-to-point data transfer schemes. Moreover, since the individual data-consuming modules are often unable to access the same data at the same time, it is difficult to configure the system so that each module processes the same data at the same time.
Furthermore, in many data processing systems, the individual modules are sometimes scheduled to operate only when they receive new data to process. Typically, a module is triggered to operate only when a selected type of new data is received. As a result, the module will not operate even when data other than the selected data are available for it to process. For example, a heart rate program may remain quiescent while it awaits new blood pressure data, even though there are new blood temperature data available that it could process. The failure of the module to operate in this situation, like the difficulties associated with inter-module data transfer, detracts from the efficiency of providing data processing systems with software packages constructed from a collection of modules.